\chapter{Ferramenta de Inspeção}
\section{Logs comportamentais de sistema}

Uma das técnicas utilizadas para análise de falhas é a produção de logs com mensagens que descrevam o comportamento do sistema, associando-as, se possível, com o valor de variáveis de contexto~\cite{araujo10}. O problema com esta técnica é que:

\begin{itemize}
	\item ela exige um esforço muito grande do ponto de vista de quem está depurando como a dificuldade de relacionar os eventos;
	\item muitos logs em um sistema real;
	\item informações de diferentes contextos misturados em uma mesma dimensão;
	\item logs distribuídos normalmente em diferentes máquinas.
\end{itemize}

O ideal para a pessoa que estiver depurando os logs seria:

\begin{itemize}
	\item poder selecionar somente os eventos do seu contexto de interesse e os visualizar em uma lista temporal única;
	\item descobrir informações;
	\item identificar relacionamentos não-explícitos entre os eventos;
	\item fornecer somente as informações necessárias para o usuário, ressaltando que este pode incorporar diferentes perfis, cada um interessado em um conjunto de diferentes informações.
\end{itemize}

Tendo como objetivo resolver os problemas citados e alcançar o ideal citado para o responsável pela depuração, a ferramenta de inspeção surgiu como uma proposta. Para ser capaz de corrigir um sistema em tempo de execução, um mecanismo que não pode faltar nesta ferramenta é a introspecção, definida como a capacidade do sistema de conhecer a si mesmo, ou seja, de disponibilizar para consulta informações sobre sua arquitetura, suas funcionalidades e seu estado em cada ponto de uma execução~\cite{staa00}. A ferramenta de inspeção possui este mecanismo que procura resolver os problemas citados através de um log em que os eventos são anotados com as informações do contexto em que foram criados, onde cada entidade geradora de log (processo, thread, máquina) notifica seus eventos para um repositório central, que os armazena de forma estruturada. Através de uma interface de consulta, é possível para um usuário estudar o comportamento do sistema filtrando os eventos a serem exibidos segundo um contexto de interesse, 
contexto este formado por um conjunto
de tags que enriquecem a informação do evento e podem ser utilizadas para indicar o que se deseja visualizar~\cite{araujo10}. 

\section{Contexto de pesquisa}

A Ferramenta de inspeção foi desenvolvida no contexto de uma pesquisa em sistemas orientados à recuperação, assumindo-se que defeitos podem existir e que~\cite{araujo10}:

\begin{itemize}
	\item em um primeiro momento, o sistema deve estar preparado,em curto espaço de tempo, para tratar das consequentes falhas a fim de evitar danos e manter os serviços disponíveis;
	\item em um segundo momento, determinar as causas dessas falhas e removê-las;
	\item ou seja, durante o tempo em que a falha está sendo diagnosticada, para identificar o defeito e o remover em seguida, o sistema continue em uso ainda que com funcionalidades reduzidas;
\end{itemize}

A partir da criação de uma infra-estrutura dessas, será possível escolher a estratégia mais adequada para recuperar o sistema de anomalias~\cite{araujo10}:

\begin{itemize}
	\item comportamentos inesperados;
	\item dados inconsistentes;
	\item falhas que comprometam a execução da aplicação como um todo (falha de segmentação, por exemplo).
\end{itemize}

Tendo como objetivo a correção de um sistema em tempo de execução, faz-se necessários alguns mecanismos em sua infra-estrutura, como~\cite{araujo10}:

\begin{itemize}
	\item {\bf introspecção:} O sistema deve ser capaz de conhecer a si mesmo, ou seja, deve disponibilizar para consulta informações sobre sua arquitetura, suas funcionalidades e seu estado em cada ponto de uma execução;
	\item {\bf coleta de eventos:} as informações sobre a execução de um sistema devem ser coletadas e organizadas em uma base de dados para facilitar o raciocínio sobre sua integridade. Consultas a partir de agentes internos, como mecanismos de verificação e recuperação, ou externos, como desenvolvedores depurando a aplicação;
	\item {\bf detecção de falhas:} o sistema deve apresentar mecanismos para verificar os contratos da aplicação e notificar as falhas encontradas;
	\item {\bf compensação de falhas:} capacidade de repor o sistema em um estado correto sem corrigir a falha. É necessário dispor de mecanismos para reverter os efeitos colaterais de uma falha e restaurar o sistema a um estado consistente mesmo que não se tenha corrigido as consequências da falha;
	\item {\bf recuperação de falhas:} capacidade de por o sistema em estado correto corrigindo o efeito da falha, ao invés de meramente por em algum estado correto. Aplicação volta à rotina normal de execução. Podemos citar, entre outras, a reexecução da atividade faltosa, a reinicialização ou substituição de componentes seguida da reexecução;
	\item {\bf flexibilidade na arquitetura:} a fim de aumentar a robustez do sistema, a sua infra-estrutura deve permitir que a aplicação continue operante ainda que possua módulos comprometidos ou inoperantes devido a falhas, e estes, possam ser restaurados a partir dos mecanismos de recuperação.
\end{itemize}

A Ferramenta de Inspeção tem como focos iniciais a introspecção e a coleta de eventos.

\section{A solução proposta}

\subsection{Arquitetura da solução}

A Ferramenta de Inspeção envolve~\cite{araujo10}:

\begin{itemize}
	\item evento representado com uma mensagem, um identificador temporal e um conjunto de tags;
	\item cada tag é representada por um par nome-valor, representando as propriedades contextuais do sistema no instante em que o evento foi criado;
	\item valor de cada tag é opcional, dependendo de sua natureza;
	\item arquitetura da solução com explicação dividida em três partes:
		\begin{enumerate}
			\item escrita das informações de introspecção;
			\item fluxo dos eventos;
			\item ferramenta para inspecionar o comportamento do sistema.
		\end{enumerate}
\end{itemize}

\begin{figure}[H]
 \begin{center}
  \includegraphics[width=0.6\textwidth]{imagens/arquitetura_solucao}
  \caption{Arquitetura da Solução~\cite{araujo10}}
  \label{fig:arquitetura_solucao}
 \end{center}
\end{figure}

\subsection{Interface de Consulta}

Alguns poucos trabalhos investem na visualização para auxiliar na inspeção manual. Estes trabalhos buscam solucionar o problema do volume de logs condensando os eventos e gerando gráficos estatísticos. É uma solução com bons resultados para detectar e diagnosticar falhas de rede e segurança, porém inadequada para falhas de lógica comportamental do sistema e que exige um nível maior de profundidade de inspeção. A Ferramenta de Inspeção segue na direção contrária, buscando mecanismos que aumentem o detalhamento dos logs ao invés de simplificá-los. Como mostrado na Figura \ref{fig:interface_consulta}, o problema de volume de logs foi resolvido através de filtros seguindo o contexto de interesse do usuário, com um grau de flexibilidade alto na sua definição, viabilizado pelas propriedades inseridas na etapa de instrumentação~\cite{araujo10}.

\begin{figure}[H]
 \begin{center}
  \includegraphics[width=1.0\textwidth]{imagens/interface_consulta}
  \caption{Interface de Consulta~\cite{araujo10}}
  \label{fig:interface_consulta}
 \end{center}
\end{figure}

Um estratégia que será adotada para auxiliar a Ferramenta de Inspeção é a análise de sensibilidade~\cite{cheung80} que irá determinar onde a capacidade de tolerância a faltas deve ser introduzida com maior efetividade. Essa análise será feita por meio da análise de dependabilidade do sistema, que será feita nos capítulos posteriores. Com isso, busca-se observar se a ferramenta cobrirá possíveis pontos críticos do sistema.
